%!TEX root = report.tex


\section{Framework}
\label{sec:framework}

The code that we generate from the user's input only contains logic for bicycle computer modes. 
Therefore, we needed some framework or an incomplete application that can be combined with this code to create an executable program. 
We created a framework in Java that has all necessary parts except mode functions. 

We used AWT and Swing libraries in order to create the user interface (display, buttons, etc.). 
However, we did want the UI to resemble a real-life bicycle computer as closer as possible, so after creating a simple form with standard buttons and labels, we agreed that we need something more sophisticated. 
Neither of us had an experience in creating rich user interfaces in Java, so we spent some time looking for a solution to our problem. 
We found an open source example of how the interface we need might be implemented in Java~\cite{www:gui}. 
Although this example did not contain all necessary information, we used it as a start point in developing our GUI.

After finishing the GUI part, we needed some automatic connection mechanism between the framework and generated code. 
We studied several ways of how we can do it: (a) use Xtend not only to generate code for modes, but also to generate a code for initialization and management of these modes; (b) create modes as classes derived from some based class and take advantage of inheritance; (c) use reflection (\emph{java.reflect}) to dynamically load classes into the framework. 
Unfortunately, none of these ways are perfect. 
We found that if we use the first solution, we have to write an extremely complex code generator that is hard to understand and maintain. 
If we use the second solution, there are some problems because of different data-types in defined modes. 
In addition, in this case the user has to alter the code in the framework manually after adding or deleting a mode function, which we do not find practical. 
Finally, if we use the third way to solve the problem, we have to write a more complicated framework. 
We chose the third solution to our problem because (a) we wanted as simple code generator as possible, (b) the framework is likely to be changed less often than other parts, and thus we can keep it more complex, and (c) we wanted the end user to be involved only in writing mode using the DSL.

To simulate the real-life conditions and test the bicycle computer program meets all requirements we added a timer to our framework. 
We programmed it to raise an event each second. In the handler for this event we generated a random number of rotations, assigned this number to a specific field in a \texttt{SystemValues} class, and recalculate all modes. 
We also created a console application for testing behavior of the program in case of time overflow (more than 9:59:59) or distance overflow (more than 999.99). 

